Part 2 Dependability [Necessary] [Critical]
10 availability
11 reliability
12 safety
13 security
14 resilience

Failure BAD trust good!
	Failures affect many
	Users reject unreliable systems
Failures cost a lot
Undependable causes lost information

Can be useful without being dependable
Consider (failure is stressful)
	Hardware failure
	Software
	Operational failure
	(interact)
Look at system as a whole and interaction

10.1 Dependable [trustworthy]
	Availability
	Reliability
		Correctness
		Precision
		Timeliness
	Safety
	Security
		Integrity
		Confidentiality
	Resilience
	
	ALSO
		Repairability
		Maintainability
		Error tolerance

	Avoid (accidental) errors
	Verification and validation to discover errors
	Fault tolerant
	Guard against external attack
	Configure correctly
	Recognize attacks
	Recover from problems

10.2 System is more than the sum of its parts
	People
	Processes
	Regulations
	Computers
	Software
	Equipment

Layers
	Equipment
	OS
	Communications
	Application
	Organizational
	Social
System level view for consequences of failure
	Try to keep failure within level
	Understand how failure in other levels can affect system
	Unexpected problems tend to get dumped on systems people

Products and companies compete
	On cost, quality, delivery, service, etc.
	Government may have standards
		Regulatory bodies

10.3 redundancy and diversity
	Spare capacity
	Backup copies
	Checking code with error recovery
	Variety of validation techniques
	BUT adding complexity can introduce errors
[spacecraft and airplanes]

10.4 dependable processes
	Must use model and collect data to show process has been followed
	Repeatable not dependent on individuals
	Can use different activities 
		To supplement or complement processes
	A dependable PROCESS
		Auditable
		Diverse
		Documentable
		Robust
		Standardized
	Could include
		Requirements review
		Requirements management
		Formal methods
		System modelling
		Design and program inspections
 		Static analysis (12)
		Test planning and management

10.5	formal methods
		Mathematical models
		Proposed early in CS
		Proofs hard to do manually
		(Now there is theorem proving software)
		Usage rare, difficult
	Refinement based development
		Use trusted transformations
		Model checking
		Design errors and omissions
		Inconsistencies between specification and program
Advantages (Formal)
	Early discovery of problems
	Automatic analysis
	Transform specifications into programs
		(code generation)
	Reduced testing
Reluctance
	Hard to understand formal models
	Hard to quantify savings
	Few are trained
	Hard to scale up for larger systems
	Tool support limited
	Not compatible with agile